1. Field of the Invention
The present invention relates to the field of computer programming, and more particularly to a technique for replicating objects in distributed object systems to reduce network round trips during program execution and thereby improve system performance.
2. Description of the Related Art
A xe2x80x9cdistributed object systemxe2x80x9d is an execution environment in which objects may be located on more than one physical computer and the application programs which operate upon those objects may also be located on (and operating on) more than one computer, where the multiple computers are connected by a network. Distributed object systems may be structured as client/server systems or as multi-tier systems (where a client/server system may be considered a multi-tier system having two tiers). Such systems are well known in the art.
Performance is a significant concern when implementing distributed object systems.
Existing object distribution techniques, such as Enterprise JavaBeans (xe2x80x9cEJBsxe2x80x9d) and the Common Object Request Broker Architecture (xe2x80x9cCORBAxe2x80x9d) are based on a model where the actual remote object instances reside in a server computer and the client nodes hold on to proxies which represent the remote instances in the client computer. (xe2x80x9cJavaBeansxe2x80x9d is a trademark of Sun Microsystems, Inc. EJBs are described in xe2x80x9cEnterprise JavaBeansxe2x80x9d, hereinafter referred to as the xe2x80x9cEJB specificationxe2x80x9d, which was published by Sun Microsystems, Inc. on Mar. 21, 1998. xe2x80x9cCORBAxe2x80x9d is a registered trademark of Object Management Group, Inc.) The proxies do not contain any business behavior (i.e. executable logic) of the remote objects: they only provide remote interfaces to access the remote objects from applications executing on the client. Therefore, every single method invocation on a proxy held by a client must be immediately passed on from the proxy to the actual remote instance in the server. The message invocation is then carried out on the remote instance at the server, and upon completion a response is returned to the proxy at the client.
FIG. 1 depicts an example of a prior art object system 100 using this object distribution approach. Suppose the system of this example includes objects for employees, their managers, and their addresses. Object server 150 is shown as containing instances of Employee objects 160, Manager objects 170, and Address objects 180. Client application 110 executing in a client device has corresponding proxies (stored either in memory associated with the application, or in other locally-accessible storage) for each object class in use by the application, which in the example are depicted as Employee proxy 120, Manager proxy 130, and Address proxy 140. When the application 110 invokes a method on an Employee object 160, the method invocation is directed locally to the Employee proxy 120, which then forwards 190a a message to the actual remote instance of the Employee object at 160. The method will be executed remotely at server 150. If the method execution causes any updates to the Employee object, these updates are performed on the remote Employee object 160. The response to this message 190a is returned 190b from the Employee object 160 to the Employee proxy 120 for use by the client application 110. Similarly, method invocations on a Manager object 170 or an Address object 180 cause a message 191a or 192a, respectively, to be sent to the corresponding object located on server 150, with response 191b or 192b returned to the appropriate proxy 130 or 140.
Even with applications of moderate size, this requirement for every message and response to be transmitted across a network in this manner results in a significant amount of network traffic. This message traffic is very expensive in terms of computation time because, in addition to the time expended due to network latency, each message has to travel through several service layers and process switches on both ends of the network connection. The service layers involved may include remote name resolution, message creation and formatting, transport, reception, buffering, scheduling, and dispatch. The multiple layers and processes which are involved cause the messaging event itself to be very costly in terms of program execution overhead, regardless of the size of the message. This high expense of remote method invocations makes it very difficult in distributed object systems to fulfill the requirements of object model granularity for which object systems were designed, and to fulfill the performance requirements demanded in modern computing environments (including large-scale enterprise computing and electronic commerce systems).
Accordingly, what is needed is a technique for reducing the performance overhead, and thereby improving performance, in distributed object systems which require remote method invocation for object access.
An object of the present invention is to provide a technique for reducing performance overhead in distributed object systems.
Another object of the present invention is to provide this technique by replicating remote objects to the local system(s) which access the objects.
Yet another object of the present invention is to provide this technique where the scope of the replication is a transaction.
A further object of the present invention is to provide this technique whereby transactions are used to ensure consistency and integrity of a replicated object among multiple applications and/or users that may access the object.
Still another object of the present invention is to provide this technique whereby each subtransaction within a transaction may have an independent view of a replicated object.
Yet another object of the present invention is to provide this technique in a manner that appropriately isolates changes made to a replicated object by one or more transactions occurring in the distributed object system, as well as changes made by multiple subtransactions within a transaction.
Still another object of the invention is to provide a technique for implementing a transaction management subsystem which is optimized for replication of remote objects.
Another object of the invention is to detect data conflicts when a user or application attempts to commit changes to a replicated object in a persistent data store.
A further object of the invention is to resolve data conflicts, where possible, after they have been detected.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer program product for improving performance in a distributed object system. This technique comprises: creating a tree structure to represent one or more subtransactions of one or more concurrent and/or nested transactions which may access one or more objects stored at a remote persistent object store in the distributed object system, wherein each node of the tree structure maintains an independent view comprising a version of each object available at this node; requesting, by a selected one of the subtransactions, access to a selected one of the stored objects; determining whether the selected object is available in a particular independent view maintained by a node in which the selected subtransaction is executing; obtaining a version of the selected object and making the obtained version available to the particular independent view when the determining has a negative result; temporarily making one or more modifications to the selected object, the modifications requested by the selected subtransaction, by making the modifications to the particular independent view of the selected subtransaction; committing the modifications upon a commit request; and performing a rollback of the modifications upon a rollback request.
Obtaining a version of the selected object and making the obtained version available may further comprise: checking whether the selected subtransaction is a remote transaction; copying the version of the selected object from an ancestor node when the checking has a negative result; and replicating the version of the selected object from a remote parent node when the checking has a positive result.
The copying may further comprise: retrieving the selected object from the remote persistent object store when the selected object is not available in the independent view of any ancestor node of the selected subtransaction in the tree structure, thereby making the selected object available from the independent view of a particular one of the ancestor nodes; copying the selected object down through the tree structure to the selected subtransaction from the independent view of the ancestor node in which the selected object is available; and adding the retrieved object to the particular independent view of the selected subtransaction.
The replicating may further comprise: retrieving the selected object from the remote persistent object store when the selected object is not available in the independent view of the remote parent node or the independent view of any ancestor node of the selected subtransaction in the tree structure, thereby making the selected object available from the independent view of a particular one of the ancestor nodes; copying the selected object down through the tree structure to the remote parent node of the selected subtransaction from the independent view of the ancestor in which the selected object is available; rendering the selected object into a portable format at the remote parent node; transmitting the portable format from the remote parent node to the node in which the selected subtransaction is executing; receiving the transmitted portable format and reconstituting the selected object from the portable format at the node in which the selected subtransaction is executing; and adding the reconstituted selected object to the particular independent view of the selected subtransaction.
The committing may further comprise: performing a commit when the subtransaction is not a top-level transaction in a transaction tree, or performing the commit when the subtransaction is the top-level transaction in the transaction tree.
In one aspect, the first case may further comprise: attempting to merge the modifications to the parent of the subtransaction upon the request to commit the modifications; cancelling the commit request if the attempting process detects one or more unresolvable data conflicts with one or more separate modifications made to the selected object, wherein the separate modifications are stored by the parent in the independent view of the parent; performing the merge of the modifications to the independent view of the parent if the attempting process does not detect any of the unresolvable data conflicts; and committing the merged modifications to the independent view of the parent. The second case further comprises: committing the modifications with a copy of the selected object in the remote persistent object store; merging the modifications to a global transaction if the committing process does not detect an error condition; and discarding the top-level transaction and any subtransactions related to the top-level transaction in the transaction tree.
In another aspect, the first case may further comprise: attempting to merge the modifications to the parent of the subtransaction upon a request to commit the modifications; cancelling the commit request if the attempting process detects one or more unresolvable data conflicts with one or more separate modifications made to the selected object, wherein the separate modifications are stored by the parent in the independent view of the parent; performing the merge of the modifications to the independent view of the parent if the attempting process does not detect any of the unresolvable data conflicts; and committing the merged modifications to the independent view of the parent. The second case further comprises: committing the modifications with a copy of the selected object in the remote persistent object store; and discarding the top-level transaction and any subtransactions related to the top-level transaction in the transaction tree.
The attempting process may further comprise invoking application-specific logic to determine when the separate modifications indicate that one of the unresolvable data conflicts is found, and the merging may further comprise invoking application-specific logic to resolve any resolvable data conflicts.
Or, the attempting process may further comprise determining that no unresolvable data conflict will occur if one of an object version from a child transaction and a parent transaction which are to be merged has not been modified or where both of the object versions have been modified from the child transaction and the parent transaction, logic is applied that determines that the object versions can be successfully merged; and wherein performing the merging further comprises invoking application-specific logic to resolve any resolvable data conflicts.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.